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Abstract —  Network  management  for  Mobile  Ad  Hoc  Networks 
(MANETs)  is  a  challenging  management  problem  given  the 
intermittent  connectivity  of  the  nodes  and  the  low  bandwidth 
constraints  associated  with  these  networks.  Further,  MANET 
management  mandates  a  distributed  management  paradigm, 
which  gives  rise  to  specific  information  dissemination  challenges. 
In  order  to  manage  these  networks,  the  Network  Management 
System  (NMS)  needs  to  send  critical  network  management  alerts 
and  data  to  network  operation  centers  (NOCs)  and  the  NOCs 
need  to  send  changes  to  policies  and  configuration  files  to  the 
distributed  nodes.  The  need  to  keep  the  overhead  of  management 
traffic  to  a  minimum  and  yet  reliably  deliver  this  data  is  a 
requirement  for  any  NMS  in  this  environment.  This  paper 
examines  these  challenges  and  proposes  an  Adaptive 
Management  Plane  approach  that  overcomes  these  challenges. 
This  approach  provides  support  for  Disruption  Tolerant 
Networking  (DTN),  allowing  messages  to  reach  intermittently 
connected  nodes.  It  also  provides  a  service  to  deliver  management 
data  to  the  remote  nodes  according  to  the  information 
dissemination  requirements  that  regulate  the  expiration,  revision 
and  confirmation  of  the  data.  In  addition,  the  approach  provides 
support  for  above  Multi-Topology  Routing  (MTR),  allowing  the 
NMS  to  deliver  data  of  different  priorities  over  multiple  networks 
that  exhibit  different  traffic  delivery  characteristics.  This 
solution  is  described  in  terms  of  an  implementation  in  the 
Dynamic  Re-Addressing  and  Management  for  the  Army 
(DRAMA)  policy-based  network  management  system. 

Keyword  -  network  operations;  MANET;  policy-based 
management;  network  management;  information  dissemination 

I.  Introduction 

Mobile  Ad  hoc  NET  works  (MANETs)  are  characterized  by 
their  capability  to  enable  networking  without  any  infrastructure 
support.  Specifically,  they  are  not  wired  and  they  have  no 
dedicated  routers.  As  they  have  no  wires,  the  nodes  use 
wireless  radios  that  are  typically  characterized  by  limited 
bandwidth  and  typically  have  high  loss  rates.  In  addition,  the 
dynamic  nature  of  tactical  MANETs  (i.e.,  nodes  intermittently 
connected)  makes  it  hard  to  manage  their  operations  in  a 
consistent  manner  across  all  network  elements. 

Command  and  control  applications  are  challenged  when 
deployed  in  tactical  MANETs  due  to  the  constrained 
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communication  environment,  and  the  network  management 
systems  (NMS)  for  these  networks  are  also  operating  under 
these  constraints.  In  some  respects  the  NMS  is  more 
challenged  since  management  traffic  is  considered  overhead 
and  must  not  add  significant  traffic  to  this  already  bandwidth- 
constrained  environment.  The  distributed  NMS  domain  for 
MANETs  requires  management  data  be  exchanged  for  several 
purposes:  1)  distribution  of  new/updated  management  rules  as 
mission  communication  requirements  change  during  the 
mission  (in  the  case  of  policy-based  network  management 
systems  this  would  be  the  dissemination  of  new  policy  rules); 
2)  distribution  of  new/updated  configuration  data  when 
network  reconfiguration  is  required  (due  to  equipment  failures 
and/or  revised  mission  plans);  and  3)  remote  reporting  of 
network  alarms/alerts/data  to  the  network  operations  center  for 
management  oversight.  A  robust  and  adaptive  management 
traffic  solution  to  address  the  operational  communication 
challenges  of  MANETs  is  a  requirement  for  the  NMS. 

This  paper  discusses  an  Adaptive  Management  Plane 
(AMP)  to  overcome  these  challenges.  The  focus  of  this  work  is 
to  provide  for  the  efficient,  robust,  and  timely  dissemination  of 
management  information.  This  management  plane  provides  an 
NMS  service  to  deliver  management  data  to  the  remote  nodes 
according  to  information  dissemination  requirements  that 
regulate  the  expiration,  revision  and  confirmation  of  the  data.  It 
also  provides  support  for  Disruption  Tolerant  Networking 
(DTN),  allowing  messages  to  reach  intermittently  connected 
nodes.  In  addition,  the  approach  provides  support  for  above 
Multi-Topology  Routing  (MTR),  allowing  an  NMS  to  deliver 
management  data  of  different  priorities  over  multiple  networks 
with  different  traffic  delivery  characteristics.  Section  II 
provides  a  review  of  the  goals  for  the  Adaptive  Management 
plane.  Section  III  presents  an  overview  of  the  NMS  used  for 
this  work.  Section  IV  presents  the  AMP  Design,  Section  V  is  a 
discussion  on  implementation  and  concluding  remarks  are  in 
Section  VI. 

II.  Goals  for  the  Adaptive  Management  Plane 

In  order  to  design  an  adaptive  management  plane  for  NMS 
traffic,  it  was  important  to  identify  the  key  requirements  for 
this  communications  infrastructure  in  terms  of  dissemination 
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requirements  and  networking  requirements.  These  are 
presented  below. 

A.  Management  Information  Dissemination  Characteristics 

The  NMS  has  diverse  dissemination  requirements  for  data 
exchanged  between  the  management  nodes.  In  order  to  capture 
these  requirements  we  took  a  look  at  the  various  types  of  data 
the  NMS  exchanges  between  the  distributed  management 
nodes.  The  reason  for  doing  this  was  to  identify  the  key 
dissemination  characteristics  of  the  NMS  traffic  that  needed  to 
be  supported  by  the  communications  infrastructure.  The 
following  is  a  summary  of  key  NMS  information  classes  we 
analyzed: 

•  Policies  -  A  policy-based  NMS  will  need  to 
disseminate  new/changed  policy  rules  to  all  nodes. 
Policy  rules  need  to  be  consistent  on  all  nodes  and  the 
order  in  which  rules  are  received  by  a  node  is 
important  for  the  semantic  integrity  of  the  policy  rule 
database.  The  distribution  of  the  policy  rules  is  usually 
done  when  the  rules  change;  also,  activation  of  rules  is 
expected  to  take  effect  immediately. 

•  Configuration  Data  -  Changes  to  configuration  data 
and/or  configuration  scripts  must  be  distributed  to 
nodes.  In  some  cases  these  changes  will  need  to  go  to 
all  nodes,  and  in  some  cases  only  a  subset  of  the  nodes 
need  to  receive  the  updates.  The  configuration  data 
can  be  large  (3-1  OK  bytes  in  size)  and  often  there  are 
multiple  files  of  data  that  need  to  be  sent. 

•  Events  -  Network  Management  events  (alarms/alerts) 
must  be  reliably  sent  to  the  network  administrators 
responsible  for  managing  the  network  (i.e.,  to  a 
centralized  NOC).  In  addition,  system-wide  changes  in 
mission  status  that  affect  networking  resources  (e.g., 


change  in  INFOCON  level,  change  in  mission  phase) 
can  generate  mission  events  (automatically  or  user- 
initiated)  that  need  to  be  reliably  delivered  to  all  or  a 
designated  subset  of  nodes  in  the  network.  These 
mission  events  are  often  the  trigger  for  policy  rule 
enforcement.  The  event  messages  are  typically  small 
in  size  (less  than  IK  bytes  in  size). 

•  Reports  -The  NMS  will  sometimes  need  to  send 
network  management  data  from  the  distributed  nodes 
to  the  network  administrators  responsible  for  managing 
the  network. 

Report  data  (such  as  SNMP  MIB  data)  may  need  to  be 
sent  periodically  to  the  NOC.  If  the  report  for  a 
particular  time-interval  cannot  be  delivered  to  the  NOC 
(due  to  limited  connectivity  and/or  reduced 
bandwidth),  and  a  new  report  is  available  for  a 
subsequent  time  interval,  the  NMS  may  want  to  only 
send  the  most  current  report.  This  capability  will  make 
more  efficient  use  of  the  limited  bandwidth  available  in 
an  ad  hoc  network.  In  addition,  some  reports  are  not 
useful  if  they  are  not  received  at  the  destination  within 
a  specific  amount  of  time  after  the  generation  of  the 
report.  The  capability  to  expire  a  report  (and  not  send 
the  outdated  data)  is  another  capability  that  is  useful  in 
this  bandwidth-limited  environment. 

Based  on  the  above  characterization  of  the  data,  we  were 
able  to  identify  (10)  attributes  of  the  data  (e.g.,  confirmation 
messages,  new  data  overrides,  data  not  yet  sent,  expire  data, 
etc.)  that  are  key  capabilities  that  will  need  to  be  supported  by 
the  communications  infrastructure  for  NMS  traffic.  Table  I 
below  captures  these  attributes  for  each  of  the  information 
classes  we  analyzed. 


TABLE  I.  NMS  TRAFFIC  ATTRIBUTES 


Type  of  Data 

Size 

Frequency 

Timeliness  ? 

Later  Data 
Overrides 

Order? 

Reliability 

Confirmations? 

Scope 

Expire? 

Compression? 

DRAMA  Policies 

S 

-  On-demand 

-  At  mission 
start  can  be 

Immediate 

Sometimes 

Y 

H 

N 

ALL 

N 

N 

Configuration 

Files 

L 

-  On-demand 

-  At  mission 

start  can  be 
bursty 

Sometimes  done 
in  advance  of 

use 

Yes 

Y 

H 

Y 

ALL  and/or 
Selected 

Maybe 

Y 

Scripts 

M-L 

-  On-demand 

-  At  mission 
start  can  be 
bursty 

Sometimes  done 
in  advance  of 

use 

Yes 

Y 

H 

Y 

ALL  and/or 
Selected 

Maybe 

Y 

Events 

S 

-  OnDemand 

-  Bursty 

-  Periodic 

Immediate 

No 

Y 

H-M 

N 

ALL  and/or 
Selected 

Y 

N 

Query/Request 

S 

-  On-Demand 

Immediate 

No 

Sometimes 

M-L 

N 

ALL  and/or 
Selected 

Y 

Maybe 

Reports 

S-L 

-  OnDemand 

-  Bursty 

-  Periodic 

Imnediate 

(On-demand 

rpts) 

Background 
(Periodic  rpts) 

Maybe 

N 

M 

N 

Send  to 
TOC 

Y 

Maybe 

Rules/Settings 

S-M 

-  On-Demand 

Sometimes  done 
in  advance  of 

Yes 

Y 

H 

Y 

ALL 

N 

N 

Network  Plans 

L 

-  On-demand 

-  At  mission 

start  can  be 
bursty 

Sometimes  done 
in  advance  of 

use 

Yes 

Y 

H 

Y 

ALL 

N 

Y 
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These  attributes  provided  the  requirements  for  AMP’s  data 
distribution  service  as  it  relates  to  the  wide  range  of  NMS 
message  traffic. 

B.  Networking  Support 

In  addition  to  the  dissemination  requirements  described 
above,  we  investigated  two  networking  technologies  that  are 
applicable  to  airborne  military  ad  hoc  networks.  Our  goal  was 
to  incorporate  technologies  that  are  relevant  to  the  limited  end- 
to-end  connectivity  in  the  airborne  network  and  to  the  multiple 
radio  links  on  the  airborne  network  nodes  that  can  provide  for 
prioritized  network  operation  communications. 

1)  Disruption-Tolerant  Networking  (DTN)  Technology 

Disruption-tolerant  networking  research  [1]  [2]  [3]  [4]  [5] 

and  [6]  has  been  focused  on  the  delivery  of  messages  where  the 
nodes  in  the  network  are  intermittently  connected  and  the 
network  does  not  provide  end-to-end  connectivity  for  a 
significant  amount  of  time.  Such  networks,  which  include 
airborne  networks  under  certain  circumstances,  pose  some 
major  challenges.  The  first  challenge  is  that  traditional  reliable 
network  transport  protocols  such  as  TCP  cannot  be  used  as 
they  require  end-to-end  connectivity.  The  second  challenge  is 
that  of  message  buffering  and  message  forwarding,  as  packets 
may  need  to  be  stored  by  an  intermediate  forwarding  entity 
when  there  is  no  route  to  the  destination  until  such  a  route 
becomes  available. 

While  utilizing  store-and-forward  technology  does  provide 
benefits,  especially  in  dealing  with  the  lack  of  end-to-end 
connectivity  of  nodes  in  airborne  ad  hoc  network,  it  is  also  a 
challenging  requirement.  The  topology  of  the  nodes  is  not 
known  a  priori;  and  therefore  determining  the  appropriate 
forwarding  entity  (entities)  needed  to  deliver  the  data  to  the 
destination  node(s)  is  a  difficult  problem.  Given  that  the  best 
store-and-forward  route  to  the  destination  node  is  not  known 
ahead  of  time  (and  if  it  is  known,  it  is  not  guaranteed  to  remain 
exactly  as  planned),  it  is  therefore  necessary  that  the  NMS 
dynamically  learn  the  appropriate  “store-and-forward 
topology”  of  the  network. 

2)  Multi-Topology  Routing  (MTR)  Technology 

Multi-topology  routing  introduces  the  capability  to 

configure  service  differentiation  through  class-based 
forwarding.  MTR  has  been  published  by  IETF  as  RFC  4915  [7] 
and  has  been  supported  by  major  manufacturers  including 
Cisco  and  Juniper.  MTR  provides  multiple  logical  topologies 
over  a  single  physical  network.  Service  differentiation  can  be 
achieved  by  forwarding  different  traffic  types  over  different 
logical  topologies  that  could  take  different  paths  to  the  same 
destination  and  thereby  result  in  different  loss  and  delay 
characteristics  due  to  different  link-layer  and  physical  layer 
technologies  over  these  paths  [8]. 

Utilizing  MTR  capabilities  in  the  network  provides 
mechanisms  for  the  NMS  to  prioritize  management  traffic. 
Traffic  can  be  marked  with  different  DSCPs  by  the  NMS  to  use 
different  network  paths  to  best  meet  their  distribution 
requirements.  For  example,  for  information  that  is  not  latency- 
sensitive  but  requires  relatively  reliable  delivery,  a  satellite  link 
could  be  the  best  transmission  choice.  The  NMS  can  monitor 
the  condition  of  different  radio  networks  to  make  information 


distribution  decisions  based  on  the  various  criteria  discussed 
earlier  in  this  section. 


III.  The  DRAMA  System 

The  NMS  capability  described  in  this  paper  is  implemented 
in  the  Dynamic  Re-Addressing  and  Management  for  the  Army 
(DRAMA)  system.  Telcordia  Technologies  developed  policy- 
enabled  intelligent  agent  technologies  for  the  U.S.  Army 
Communications  Electronics  Research  and  Development 
Engineering  Center  (CERDEC)  under  the  DRAMA  Science 
and  Technology  Objective  (STO)  to  cope  with  the  unique 
management  challenges  posed  by  the  future  military  tactical 
networks  [9]  and  [12].  After  the  DRAMA  technology  was 
successfully  demonstrated  as  a  solution  for  the  Army  tactical 
network  domain,  the  Air  Force  Research  Laboratory  (AFRL) 
subsequently  leveraged  the  Army’s  investment  in  its  NATM 
program  [10]  and  [11]  to  investigate  its  suitability  as  a  solution 
for  network  management  in  the  airborne  network  domain, 
which  culminated  in  the  Government’s  successful  employment 
of  the  DRAMA/NATM  technology  in  three  live-fly 
demonstration  events. 


The  DRAMA  system  employs  a  distributed-agent 
architecture,  and  possesses  self-adapting,  self-organizing,  and 
self-healing  capabilities  that  are  essential  for  managing 
dynamic  military  tactical  networks.  The  DRAMA  system 
features  policy  control,  which  allows  networks  to  be  managed 
by  policies  that  can  be  tailored  for  different  missions.  The 
policy  agents  in  DRAMA  are  organized  into  a  tree-like 
management  hierarchy.  The  purpose  of  this  organization  is  to 
create  a  hierarchy  of  distributed  managers  as  depicted  in  Fig  1. 
At  the  leaves  of  the  tree  will  be  the  Local  policy  Agents  (LPAs) 
that  are  responsible  for  gathering  status  and  managing 
networking  elements  on  the  local  node.  Domain  Policy  Agents 
(DP As)  are  intermediate  nodes  in  the  tree  hierarchy;  they 
receive  summarized  reports  from  subordinate  DRAMA 
instances  (LPAs)  and  manage  local  elements.  DP  As  report  the 
combined  status  of  their  local  elements  and  their  subordinate 
reports  to  their  respective  masters,  which  could  be  other  DP  As 
or  the  Global  Policy  Agent  (GPA).  At  the  top  of  the  hierarchy 
is  the  GPA  that  receives  reports  from  subordinates  and  forms 
the  root  of  the  tree. 


GPA  manages  a  collection  of 
DPAs  and  LPAs  % 


Air  Operations  Center 


Management  status  is  reported  up 
the  management  hierarchy 


Policies  are  disseminated  from 
GPA  to  DPAs  to  LPAs, 
from  DPAs  to 


GPA:  Global  Policy  Agent 
DPA:  Domain  Policy  Agent 
LPA:  Local  Policy  Agent 

Figure  1  -  DRAMA  Management  Hierarchy 


DRAMA  is  a  policy-based  network  management  system. 
Policy  rules  are  triggered  by  Events,  limited  by  Conditions,  and 
result  in  enforcement  of  Actions  (thereby  sometimes  referred  to 
as  EC  A  rules).  The  DRAMA  policy  management  function 
listens  for  events.  When  it  detects  an  event  that  matches  that  of 
an  active  policy,  the  policy  management  function  triggers  the 
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policy.  Inactive  policies  are  never  triggered.  When  a  policy  is 
triggered,  the  policy  management  function  evaluates  the 
conditions  specified  in  the  policy.  If  the  conditions  of  a 
triggered  policy  hold  (are  true),  the  policy  management 
function  enforces  the  policy  by  taking  the  actions  specified  in 
the  action  section  of  the  policy. 

IV.  Design  of  the  Adaptive  Management  Plane 

The  Adaptive  Management  Plane  (AMP)  in  DRAMA 
provides  the  communications  support  for  network  management 
traffic.  This  communications  support  is  provided  by  both  the 
CommStack  software  (within  the  Hierarchical  Group 
Infrastructure  component)  and  the  AMP  Distribution  and 
Transport  layer  components.  CommStack  communications  is  a 
distribution  mechanism  that  was  described  in  an  earlier  paper 
[13]  See  Fig.  2  below  for  an  overview  of  the  AMP  components. 

Other  AID  Applications 


SendDramaEventToGPA  Action  DRAMA 

(Policies) 

nPAMA  Aincomipo 


Figure  2  -  DRAMA  AMP  Components 


DRAMA  supports  the  following  messages  between 
DRAMA  nodes: 

•  GPA  messaging  (sending  data  to  the  centralized  NOC) 

•  File/Event  distribution  messaging 

•  Policy  rule  distribution  messages 

•  Hierarchy  formation  messages. 

For  the  first  two  items  (GPA  messaging  and  File/Event 
distribution),  DRAMA  was  enhanced  to  use  AMP 
communications  and  this  messaging  is  the  focus  of  this  paper. 
DRAMA  was  extended  to  provide  a  communications  service 
that  is  callable  by  other  DRAMA  components.  The  API  that  is 
used  to  call  this  communications  service  is  referred  to  as  the 
Adaptable  Information  Distribution  (AID)  API.  In  addition, 
another  AMP  API  is  available  to  allow  policy  actions  to  control 
some  aspects  of  AMP  communications.  This  API  allows 
policy  rules  to  be  written  to  autonomously  control  the  behavior 
of  the  AMP  (e.g.,  turning  data  compression  on/off  based  on 
network  conditions,  tuning  rescan  intervals,  etc. . .). 

The  3rd  item  (policy  rule  distribution  messages)  uses  the 
legacy  CommStack  communications  in  the  Hierarchical  Group 
Infrastructure  component.  During  this  phase  of  AMP 
implementation  we  did  not  change  the  communications 
mechanism  for  this  data.  We  expect  that  future  work  will 
address  this  support.  The  last  item  (hierarchy  formation 


messages)  will  not  use  AMP  since  these  messages  provide  the 
basic  node/cluster  information  needed  by  the  AMP 
infrastructure  that  will  be  discussed  in  this  paper  (see  the  AMP 
Hierarchical  Group  Infrastructure  section  below). 

A.  AMP  Hierarchical  Group  Infrastructure 

The  Hierarchical  Group  Infrastructure  (HGI)  component  is 
used  to  create  a  hierarchy  of  distributed  managers.  More 
specifically,  the  clustering  algorithms  in  this  component  are  the 
mechanism  that  allows  the  distributed  nodes  to  form  a 
management  hierarchy.  A  cluster  is  a  set  of  nodes  arranged  in 
hierarchy  up  to  a  root.  If  the  network  becomes  partitioned 
(e.g.,  due  to  mobility),  there  will  be  multiple  clusters.  When 
nodes  in  one  cluster  move  within  communications  range  of 
another  cluster,  the  HGI  components  merge  the  clusters. 

This  component  contains  the  clustering  algorithms  that  use: 
1)  heartbeat  messages  (to  determine  the  connectivity  to 
children)  and  2)  probing  messages  (to  find  a  parent)  in  order  to 
maintain  the  management  hierarchy.  In  addition,  this 
component  exchanges  additional  messages  (clustering 
messages)  which  are  sent  up  the  hierarchy  with  grandchildren 
information.  As  the  messages  go  up  the  hierarchy,  these 
messages  then  contain  information  about  grandchildren,  great¬ 
grandchildren,  etc.  When  the  information  reaches  the  root  of 
cluster,  the  cluster- wide  view  of  all  the  nodes  is  available.  The 
roofs  view  of  the  set  of  nodes  in  its  cluster  is  periodically  sent 
to  down  the  hierarchy  to  all  the  nodes  if  that  data  has  changed. 

The  HGI  component  supports  the  AMP  Distribution  and 
Transport  layers.  For  the  AMP  distribution  layer,  this 
component  provides  membership  information.  For  example, 
when  the  AMP  distribution  layer  needs  to  resolve  a  reserved 
name  (i.e.,  PARENT,  CHILDREN,  ALL,  ALL-SATCOM)  into 
a  list  of  specific  node  names,  it  is  this  component  that  provides 
that  functionality.  In  addition,  this  component  provides  current 
cluster  information  to  the  AMP  distribution  layer.  For  example 
it  provides  the  list  of  nodes  in  current  cluster. 

The  HGI  component  also  provides  historical  clustering 
information  to  the  AMP  transport  layer.  For  example,  when 
the  AMP  layer  needs  to  determine  the  next  hop  in  a  DTN 
distribution,  it  is  the  HGI  component  that  has  the  historical 
view  of  what  other  clusters  the  destination  node  has  been  a  part 
of  and  the  historical  members  of  those  clusters.  Using  this 
information,  the  HGI  component  can  provide  a  list  of  nodes 
that  can  possibly  be  used  as  the  next  hop  to  reach  a  node  not 
currently  in  the  sending  nodes  cluster  (further  information  on 
the  DTN  support  is  discussed  below). 

B.  AMP  Distribution  Layer 

The  AMP  distribution  layer’s  primary  objective  is  to 
provide  bandwidth-efficient,  robust  message  delivery  to 
recipient(s).  To  do  this,  the  AMP  distribution  layer  is 
responsible  for  two  functions:  1)  providing  an  adaptable 
information  distribution  framework  needed  to  fulfill  the 
delivery  requirements  of  the  data  (e.g.,  confirmations, 
expiration,  replacing  updated  data  if  not  yet  sent,  etc...)  and  2) 
determining  whether  DTN  or  MTR  should  be  invoked  before 
passing  messages  to  the  message  transport  layer. 
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1)  Adaptable  Information  Delivery  (AID)  Framework 

The  AID  framework  is  composed  of  two  major 
components:  AidChannel  and  AidLayeredStack.  AidChannel 
interfaces  with  the  AID  client  to  send/receive  messages  and  the 
AidLayeredStack  processes  messages. 

An  AID  client  sends  and  receives  messages  through  an 
AidChannel.  Each  AidChannel  is  equipped  with  an 
AidLayeredStack.  The  stack  contains  a  stack  of  message 
processing  layers.  The  following  processing  layers  are  defined: 

•  Confirmation  Layer  -  on  the  receiving  end,  this  layer 
generates  an  AIDConfirmation  message  to  the  sender  of  the 
AIDMessage,  if  the  AIDMessage  is  marked  as  “confirmation 
needed”.  On  the  sending  end,  this  layer  forwards  the 
confirmation  up  to  the  Application,  if  the  message  is  marked  as 
“confirmation  needed”. 

•  Compression  Layer  -  this  layer  compresses  the  outgoing 
message  and  decompresses  the  incoming  message,  if  the 
message  requested  compression. 

•  Expiration  Layer  -  this  layer  drops  incoming  messages 
that  have  expired. 

This  framework  also  provides  the  capability  to  “update” 
messages  in  the  outgoing  queue.  When  an  application  wants  to 
update  a  previous  send  message  request  with  newer  content, 
the  client  uses  the  same  message  ID  (AID  returns  a  message  ID 
to  the  client  when  called  to  send  data)  and  calls  the  AID 
framework  with  the  new  content  and  new  expiration  time.  The 
recipients  and  delivery  confirmation  are  copied  over  from  the 
previous  send  request. 

a)  Policy  Control  of  AMP 

The  AMP  provides  an  API  to  change  various  AMP 
parameters  for  one  or  more  channels  (e.g.,  turning  data 
compression  on/off  based  on  network  conditions,  tuning 
interval  which  the  transport  layer  with  retry  sending  messages 
in  the  transport  queues,  etc.).  This  API  was  used  in  a  new 
DRAMA  action  (AidChannelConfigurationAction).  In  this 
way  a  DRAMA  policy  rule  can  be  written  to  allow  automatic 
(based  on  network  conditions/e  vents)  or  network  administrator- 
initiated  (based  on  manual  trigger  event)  triggering  of  this 
action.  In  this  way  the  AMP  communications  can  adapt  to 
network  and  mission  conditions. 

2)  Distribution  Mechanism  Selection 

The  AMP  distribution  layer  also  is  responsible  for 
determining  whether  DTN  or  MTR  should  be  invoked  before 
passing  messages  to  the  message  transport  layer. 

a)  MTR  Decision 

AMP  messages  can  have  a  client-specified  priority.  In  the 
current  implementation  of  DRAMA,  we  support  SATCOM  and 
NON-SATCOM  priorities.  If  the  DRAMA  installation  is 
configured  with  SATCOM  interfaces  on  one  or  more  of  the 
nodes,  then  the  MTR  capability  can  be  used.  When  a 
SATCOM  distribution  is  requested  by  the  client,  the 
distribution  layer  will  mark  these  messages  for  MTR 
processing  and  pass  the  messages  to  the  AMP  transport  layer. 


a)  DTN  Decision 

If  a  NON-SATCOM  message  is  to  be  sent,  the  AMP 
distribution  layer  will  determine  whether  the  message  should 
use  the  DTN  for  transport.  Lor  each  destination  in  the  request, 
this  function  will  first  see  if  it  has  connectivity  to  that  node 
using  its  current  cluster  information.  If  it  does,  it  will  send  that 
request  to  the  AMP  transport  layer  for  non-DTN  processing.  If 
the  destination  is  not  in  the  current  cluster  then  the  message  is 
marked  for  DTN  processing  by  the  AMP  transport  layer. 

C.  AMP  Transport  Layer 

The  AMP  Transport  Layer’s  primary  objective  is  to  provide 
end-to-end  message  data  path  control  above  the  network 
transport  protocols  (e.g.,  TCP,  UDP,  etc.).  This  layer  provides 
a  persistent  store  for  all  outgoing  messages.  The  messaged  are 
safe  stored  so  that  messages  are  not  lost  across  DRAMA 
restarts  and  when  nodes  are  disconnected.  When  messages  are 
received  by  this  layer,  they  are  placed  in  queues  for  processing. 
There  are  currently  three  queues  that  this  layer  services:  1) 
Direct  queue,  2)  MTR  queue  and  3)  DTN  queue.  Messages  are 
not  deleted  from  the  queue  until  they  have  been  successfully 
delivered  to  either  their  destination  (Direct/MTR  queues)  or  to 
their  next  hop  (DTN  queue).  Messages  in  the  Direct  Queue  are 
sent  to  the  destination  node  using  their  AidChannel. 

a)  MTR  Transport 

As  mentioned  earlier,  MTR  provides  mechanisms  for  the 
NMS  to  prioritize  management  traffic.  Traffic  can  be  marked 
with  different  DSCPs  by  the  NMS  to  use  different  distribution 
paths  to  best  meet  their  distribution  requirements.  During 
DRAMA  startup,  MTR  pre-processing  will  take  place  if  any 
DRAMA  AidChannels  have  been  defined  with  SATCOM 
transport.  The  properties  for  these  SATCOM  AidChannels  will 
be  read  in  by  the  MTR  pre-processing  function.  This  function 
will  then  install  ipTables  rules  based  on  these  properties. 
These  rules  will  mark  any  packets  that  contain  the  port  and 
protocol  of  a  SATCOM  AidChannel  with  a  specific  TOS  bit 
setting  (DSCP  value).  Thus  with  the  capabilities  of  an  MTR- 
enabled  network,  these  messages  can  be  delivered  over  a 
different  distribution  path  than  NON-SATCOM  messages. 
Messages  in  the  MTR  Queue  are  sent  to  the  destination  node 
using  their  AidChannel. 

a)  DTN  Transport 

DTN  transport  focuses  on  the  delivery  of  messages  where 
the  nodes  in  the  network  are  intermittently  connected  and  the 
network  does  not  provide  end-to-end  connectivity  for  a 
significant  amount  of  time.  At  the  AMP  transport  layer  the 
next  hop  for  the  message  must  be  determined.  The  next  hop 
for  a  message  is  determined  using  cluster  information  provided 
by  the  AMP  HGI  component. 

The  HGI  component  maintains  current  cluster  information 
as  well  as  historical  cluster  information.  When  the  AMP 
transport  layer  sends  a  “ get-next-hop ”  request  to  the  HGI 
component,  the  HGI  component  will  return  a  weighted  list  of 
possible  next  hops. 

Lor  example,  suppose  we  are  trying  to  send  data  from  the 
source  (node  S)  to  the  destination  (node  D),  over  an 
intermittently  connected  network  (as  shown  in  Lig.  3,).  In  this 
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network  the  connectivity  is  such  that  we  have  (3)  clusters  (S,  c 
and  g).  We  have  two  nodes  that  transit  between  the  clusters 
(nodes  fa  and  fz).  This  node  intermittently  appears  in  clusters  S, 
C,  and  g  (not  at  the  same  time).  Nodes  fa  and  fz  can  be  viewed 
as  the  “ferry”  nodes  that  can  transport  the  message  to  the 
destination  (and  in  reverse  ferry  the  confirmation  back  to 
source  node  if  requested). 


The  HGI  component  will  determine  the  list  of  nodes  that 
have  transited  to  the  destination  cluster  (the  cluster  that 
contains  the  destination  node)  at  some  point  in  the  past,  as  well 
as  any  intermediate  clusters  that  the  nodes  in  the  destination 
cluster  have  belonged  to  at  some  point  in  the  past.  This  list  of 
nodes  will  be  weighted  by  when  they  were  last  in  the 
destination  cluster  (i.e.,  exit  time)  and  how  long  they  were  in 
the  destination  cluster  (i.e.,  duration).  If  no  nodes  are  returned, 
the  transport  layer  will  leave  the  message  in  the  queue  until  the 
next  retry  interval.  If  the  one  or  more  nodes  are  returned,  the 
transport  layer  will  select  the  highest  weighted  node  to  be  the 
next  hop  to  get  the  data  to  the  destination,  and  will  send  the 
data  to  this  next  hop.  This  get-next-hop  processing  is  repeated 
at  each  intermediate  destination. 

V.  Implementation 

We  have  performed  initial  testing  of  the  AMP  functionality 
in  the  DRAMA  system  over  a  simulated  radio  network 
implemented  in  the  Virtual  Ad-Hoc  Network  (VAN)  testbed 
[14]  with  simulated  airborne  platforms  on  a  radio  network.  The 
simulation  model  chosen  for  the  wireless  network  was  the 
Wireless  Transport  Network  developed  by  Avaliant,  LLC. 

Our  simulated  environment  consisted  of  a  10-platform 
wireless  network.  The  simulation  scenarios  included  movement 
of  the  platforms  to  create  various  arrangements  of 
intermittently  connected  nodes  on  the  network.  In  all  cases  the 
DRAMA  messages/files  were  successfully  delivered  to  the 
destination  platform(s). 

VI.  Summary  and  Future  Work 

The  Adaptive  Management  Plane  provides  a 
communication  service  for  network  management  traffic  that  is 
capable  of  dealing  with  the  intermittent  connectivity  and  low 
bandwidth  requirements  of  tactical  military  mobile  ad  hoc 
networks.  In  addition,  the  AMP  provides  information 
dissementation  capabilities  that  are  applicable  to  network 
management  traffic.  AMP  functionality  has  been  implemented 
and  tested  on  simulated  wireless  networks  with  good  results. 


Future  work  will  include  further  testing  of  the  AMP 
functionality  and  performance  testing  of  the  functionality  in  the 
simulated  network. 
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